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Filed: October 5, 2000 

For: Device Detection System and Method 

REPLY BRIEF RESPONSIVE TO EXAMINER'S ANSWER 

Mail Stop: Appeal Brief-Patents 
Commissioner for Patents 
P.O. Box 1450 

Alexandria, Virginia 22313-1450 
Sir: 

The Examiner's Answer mailed February 27, 2006 has been carefully considered. In 
response thereto, please consider the following remarks. 
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REMARKS 

The Examiner has provided in the Examiner's Answer various responses to arguments 
contained in Applicant's Appeal Brief. Applicant addresses selected responses in the following. 

A. Determining What Peripheral Devices are Connected to Other Computers 

The Examiner begins his discussion of Applicant's arguments by stating that Applicant 
argues that Goshey does not disclose a program or component that is configured to "determine" 
what peripheral devices are connected to other computers. 

Applicant notes that the above is not an explicit limitation of Applicant's claims. 
Therefore, Applicant declines to comment on the Examiner's argument and instead addresses the 
actual limitations of Applicant's claims in the following. 

B. Sending a Scan Request 

The Examiner argues that: "Goshey teaches the system and method where the client is 
capable of sending a 'get support info command'. In response to the request, a request is sent to 
the servers connected on the network to identify the host adaptors and the peripheral devices 
connected to each of the servers." The Examiner then identifies column 8, line 50 to column 9, 
line 61 of the Goshey reference for support. Applicant disagrees with the Examiner's 
interpretation as to what Goshey teaches. 

Column 8, line 50 to column 9, line 61 of the Goshey reference provides as follows: 

. . . overhead while providing acceptable performance across a network. 

A typical RPC subsystem is based on a Client/Server model of 
functionality. This means that the Client is free to call upon the Server to perform 
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various tasks whenever the Client desires. Although this method works well, a 
standard RPC does not provide a way for the Server to call its Clients whenever it 
desires. For example, the Server is conventionally only allowed to send a message 
to a Client when the Server is processing a request from a Client. 

To remedy this problem, a second Client/Server interface is created. In this 
embodiment, the second Client/Server interface (i.e., a call-back sub-interface) is 
configured to pass messages from the Server to the Client. To accomplish this, the 
Server ScanLAN application is set to respond as if it were a Client ScanLAN 
application, and the Client ScanLAN application is set to respond as if it were a 
Server ScanLAN application. Once the Client and Server respond as described 
above for the purpose of sending messages from the Server to the Client, the 
Server application can send a number of informative messages to the Client 
during its operation. 

For example, when a computer running a Server ScanLAN application is 
about to be shutdown, that Server will send a message to all Clients informing 
them of the shutdown so they can clean up any of their applications that are using 
the Server (i.e., a peripheral device that is connected to the Server). Another 
example of when the Server needs to send a message to the Clients is when a wait 
queue is accessed, and the Server needs to let the next Client know it can now use 
a device that is connected to the Server. Other messages may include plug-n-play 
messaging. 

Referring back to the Server ScanLAN window 340 of FIG. 3C, the user 
may select one of the peripheral devices 1 18, 120, or 121, and then designate them 
to be "Shared or Not shared" by one of the Clients 342 by right-clicking on one of 
the Clients 342. For example, as shown in FIG. 3D, when the Client 112d is 
selected, the user can modify the sharing rights to a particular peripheral device. 
Window 350 therefore shows the list of devices that are connected to computer 
112b that has the Server ScanLAN application. Further, the user is able to view 
and/or modify the Client's sharing rights by first selecting a device from the list of 
devices, and then view and/or modify the sharing rights 352. 
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In this example, the scanner 118 is selected and is marked to be shared 
from the sharing rights 352. Once the sharing rights have been modified in 
accordance with the user's desire, the sharing rights will become effective once the 
OK or the APPLY icon is selected from window 350. Of course, the sharing rights 
of any one of the other peripheral devices or the host adapter can also be modified. 

FIG. 3E shows a properties window 360 in accordance with one 
embodiment of the present invention. When the user selects the scanner 118 from 
the list of devices shown in FIG. 3D, the particular sharing rights for that 
peripheral device will be appropriately identified. As shown, the scanner 118 is 
selected to be a "shared" peripheral device. In addition, the properties window 360 
shows the device reservation data for that scanner 118. 

FIG. 3F shows a Client ScanLAN window 370 in accordance with one 
embodiment of the present invention. The Client ScanLAN window 370 has a 
general selection 372, which allows the user having the Client ScanLAN 
application loaded on its computer to enable or disable the Client ScanLAN 
application. As shown, a user can enable or disable the Client ScanLAN 
application at any time by selecting that option and clicking on the APPLY button. 
When the Client ScanLAN is enabled, the user of that computer can use and share 
SCSI peripherals across the network that are physically connected to a computer 
having the Server ScanLAN application (provided that Client is given enough 
sharing privileges by the user of the Server ScanLAN application). On the other 
hand, when the Client ScanLAN is disabled, the user cannot use or share any 
SCSI peripheral device across the network. 

FIG. 3G shows the Client ScanLAN window 370 having a server list 374 
selected in accordance with one embodiment of the present invention. 

Goshey, column 8, line 50 to column 9, line 61. 

Applicant asserts that, to the contrary of that argued by the Examiner, column 8, line 50 
to column 9, line 61 says nothing whatsoever about a request that "is sent to the servers 
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connected on the network to identify the host adaptors and the peripheral devices connected to 
each of the servers." Perhaps if Goshey actually did provide such a teaching the Examiner would 
have identified that teaching with greater specificity instead of just citing an entire column of the 
Goshey reference. 

As described in the Appeal Brief, what Goshey does actually teach is presenting a list of 
peripherals available on a first computer to the user on a second computer. Despite that teaching, 
Goshey never discloses how the peripherals are located in the first place, for addition to the list. 
Instead, it is just presumed that the peripherals are known. In other words, Goshey is silent as to 
how it is first determined what peripheral devices are available on the network. 

As also described in the Appeal Brief, Goshey could have envisioned a manual process to 
determine what peripherals are connected to each host computer. It is even possible that Goshey 
may have contemplated sending scan requests from one computer to another computer. This is 
just conjecture however, and the only relevant fact is that the Goshey reference does not 
disclose that action. Therefore, the Goshey reference cannot be said to anticipate Applicant's 
claims under 35 U.S.C. § 102. 

C. Receiving a Response to the Scan Request 

As noted in the Appeal Brief, given that the Goshey reference does not disclose sending a 
scan request, it logically follows that Goshey does not anticipate receiving a response to that scan 
request. 
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D. Receiving Device Addresses and Requesting Info Directly from the Devices 

In regard to the limitation "receiving device addresses from the application program 
interface and requesting information from the devices directly via the addresses" the Examiner 
states: 



The local client receives a response from the scanLAN software installed on a 
remote computer where the list of devices are displayed to the client . . . The list 
of devices received are [sic] displayed to the user as shown in fig. 4D. Fig. 4D 
show [sic] the devices and device IDs of each device where the device ID 
represents the device address and therefore Goshey teaches requesting information 
from the devices directly via the addresses. 

Examiner's Answer, page 13, line 20 to page 14, line 3. 

With all due respect to the Examiner, the above argument makes no sense. The Examiner 
is arguing that because a "list of devices" is "displayed to the user," Goshey teaches requesting 
information from the devices? Applicant submits that the mere action of displaying a list to a 
client does not somehow include the action of requesting information from the devices. 
Therefore, Applicant maintains the argument that Goshey does not actually teach "receiving 
device addresses from the application program interface and requesting information from the 
devices directly via the addresses" as required by some of Applicant's claims. 



E. Consulting a List Prior to Sending the Scan Request 

As noted in the Appeal Brief, given that the Goshey reference does not disclose sending a 
scan request, it logically follows that Goshey does not anticipate consulting a list "prior to 
sending the scan request" as required by some of Applicant's claims. 
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F. Sending Multiple Scan Requests in Parallel 

In regard to the limitations "sending multiple scan requests to multiple remote command 
processes running on network hosts" and "wherein the scan requests are sent in parallel", the 
Examiner states: 

The system include [sic] plurality of hosts that operate independent of each other 
and the requests to identify the peripheral devices connected to each of the hosts 
sent from the same client are sent independent of each other . . . Therefore 
Goshey teaches sending multiple scan requests to multiple processes or wherein 
the scan requests are sent in parallel by sending from a client multiple independent 
requests to multiple hosts. 

Examiner's Answer, page 14, line 21 to page 15, line 4. 

As a first matter, Applicant reiterates that Goshey does not actually teach sending a scan 
request to any computer. Therefore, the argument that Goshey teaches sending multiple scan 
requests is fallacious. 

As a second matter, even if it were assumed that Goshey somehow taught sending 
multiple scan requests, Goshey certainly does not teach sending such requests "in parallel". 
Applicant notes that the Examiner identifies no portion of the Goshey disclosure that provides 
such a teaching. 
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CONCLUSION 

In summary, it is Applicant's position that Applicant's claims are patentable over the 
applied prior art references and that the rejection of these claims should be withdrawn. Appellant 
therefore respectfully requests that the Board of Appeals overturn the Examiner's rejection and 
allow Applicant's pending claims. 



Respectfully submitted, 
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